Design Comments: A unique identifier for this particular event assigned by the system in which the event occurred.

UsageNotes: Identifier needs to be persisted by receiving applications, except for queries (queries cannot be retracted or undone). The identifier must be unique and different from the event identifier that is present on the request - it must be generated by the responding application.

Rationale: Allows the event to be referenced (for undos) and also indicates whether multiple interactions were caused by the same triggering event. Also used for audit purposes.

Design Comments: Identifies the trigger event that occurred.

Rationale: This is mandatory because it is essential to understanding the meaning of the event.

Design Comments: Describes the status of the control act, which is always complete (it happened).

Rationale: Required for completeness of specification.

Design Comments: Indicates the time the event (e.g. query, change, activation) should begin and occasionally when it should end.

Rationale: The time an event becomes effective may differ from the time the event is recorded (i.e. it may be in the future or the past). For events such as 'suspend', an intended end date may also be indicated.

Design Comments: Identifies why this specific message interaction (e.g. query, activation request, modification request) occurred.

UsageNotes: The domain associated with this attribute will vary for each interaction and will be noted as part of the interaction description.

Rationale: Allows identifying a reason for a specific action, such as 'reason for hold' or 'reason for accessing information'.

Design Comments: Indicates the person responsible for the event that caused this message.

Rationale: Critical for auditing and for validating permissions and therefore mandatory.

Design Comments: Information pertaining to a client's agreement/acceptance to have his/her client identification and demographic information electronically stored and shared.

UsageNotes: This will usually only be populated for queries, but could be used for updates if a jurisdiction requires consent before recording information in the EHR (e.g. consent to participate in electronic data exchange).

Note: keywords canot be passed from one application to another via the EHR (e.g. prescriber to dispenser via a Drug Information System).

Rationale: Provides authorization to record and/or view client information.

Indicates the consent or keyword used to authorize access or update, including a reason for access; May also be used to override access restriction to the information ('break the glass') on a message by message basis.

Design Comments: This is the list of clinical and business issues that have been detected and/or managed involving the current action.

Rationale: Any trigger event can result in errors or may allow for errors to be overridden or managed.

Design Comments: Class which describes the query specifics and parameter list.

UsageNotes: Value should always be AUT

Design Comments: The time the person responsible for the event made the decision for it to occur. This may be different than the time the change became effective. (E.g. If a provider decides today to put a prescription on hold starting next Tuesday, the time of creation would be today and the change effective period would be next Tuesday.)

This date can be back-dated.

Rationale: The time a change is made is a critical piece of audit information and is therefore mandatory.

Design Comments: Indicates how the person who recorded the event became aware of it.. E.g. Verbal, written, fax, etc.

Rationale: May have ramifications for the audit trail and reliability of the information.

Design Comments: An authentication token expressed as a non-GUID string.

The Authorization token may represent the concepts of author, data enterer, supervisor (responsible party), responsible location and/or data entry location.

Rationale: Some systems may choose to use a hashcode or other approach to token construction.

Design Comments: Unique number for this particular query.

Rationale: Needed to allow continuation of queries and linking of query requests and responses and therefore mandatory.

Design Comments: This allows the sender to indicate to the receiver that this query should follow an expedited processing flow.

Rationale: Intended to convey the requested 'packaging' of query results. This attribute does not affect which rows are selected by the query, just the manner in which they are returned. For example, a batch file containing responses, a response message containing multiple payloads, or a stream of response messages (notifications) each identifying itself as a response to a query request.

Design Comments: The number of response item repetitions that should be included in the initial response.

UsageNotes: If not specified, the default behavior is to return all repetitions. However the recipient of a query may always choose to limit the quantity returned to be less than the number requested. Regardless of the number specified here, the number of rows returned will never exceed the number of matching rows based on the query parameters.

Rationale: There may be a very large number of matching rows. To manage communication bandwidth, a limited set may initially be returned with further data retrieved by using query continuations.

Design Comments: Defines the units associated with the magnitude of the maximum size limit of a query response that can be accepted by the requesting application.

Rationale: Needed to quantify the types of records requested to be returned in the query.

Design Comments: When more than one sort control is specified, this is the order of this sort element amongst the others.

Rationale: This number determines which sort element is using primarily, secondary, etc. and is therefore mandatory.

Design Comments: Name of the element to sort.

Rationale: The name of the element is mandatory.

Design Comments: Sets the ascending or descending nature of the sort request.

Rationale: This element is required.